home *** CD-ROM | disk | FTP | other *** search
/ Just Call Me Internet / Just Call Me Internet.iso / docs / protocol / rfc / rfc_txt / rfc0000 / rfc0346.txt < prev    next >
Text File  |  1997-08-06  |  3KB  |  60 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                           Jon Postel
  8. Request for Comments: 346                       Computer Science
  9.                                                 UCLA-NMC
  10. NIC : 10425                                     30 May 72
  11.  
  12. Categories :  Echo Plex, Satellite
  13. References :  RFC's 1, 5, 51
  14.  
  15.                         Satellite Considerations
  16.  
  17. The consideration of using space satellite transmission links in the
  18. ARPANET should be cause for some thought by the parties making use of
  19. the network.  The satellite transmission path will not necessarily affect
  20. the transmission rate but it will affect the delay.  The change in the
  21. delay characteristics can be approximated by the change in path length.
  22. Thus if the satellite is in synchronous orbit about 22,000 miles above
  23. the earth, the path length is about 44,000 miles compared to (worst
  24. case) 3,000 miles or about a 15 to 1 increase in path length and delay.
  25. (The time for light to travel 3,000 miles is .016 seconds, to travel
  26. 44,000 miles is .236 seconds.)
  27. In the current (surface) ARPANET delays are such that interactive
  28. servers with character-at-a-time remote echo are only marginally useful.
  29. While I believe that this delay (unmeasured) is largely due to the host
  30. systems, adding a half second transmission delay will cause these
  31. marginal systems to become unusable.
  32. Thought should also be given to buffer allocations.  If a receiving
  33. system allows only one line of text to be buffered at a time and
  34. refreshes the allocation as each line is output to a human user there
  35. will be at least a half second delay between the arrival of each line at
  36. the receiving system.  This need not be a problem until the speed of the
  37. output device is above about 150 characters/second.  This "small buffer"
  38. problem can be expected to occur even with lower speed devices since
  39. host delays are estimated to be in the range 0.1 second to 1.0 second.
  40. I suggest that it is appropriate to resume a discussion of measures to
  41. circumvent the difficulties brought about by these large delay
  42. characteristics. Some areas of discussion could be: buffer sizes in
  43. servers and users, echo plex techniques, moving part of the input
  44. processing to the user system.  If it is decided to move the echo plex
  45. functions to the user system, it would be wise to try for a "standard"
  46. package, thus reducing a M times N problem to a M plus N problem.
  47. Please dig out and read RFC's #1 Crocker, #5 Rulifson, #51 Elie to see
  48. some previous thinking about this type of problem.
  49.  
  50.        [ This RFC was put into machine readable form for entry ]
  51.        [ into the online RFC archives by BBN Corp. under the   ]
  52.        [ direction of Alex McKenzie.                   12/96   ]
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60.